Flash memory systems have become very common in recent years. Due to certain characteristics of flash memory devices, the handling of memory systems based on such devices is not trivial and requires dedicated software to handle the writing to and reading from these devices, thus simplifying the use of the storage system for the user application. For example, NAND-type flash memory is typically written (also called “programmed”) in chunks called “pages” (typically having the size of 512 bytes to 2K bytes). A flash page should not be written to unless the page is previously erased (all bits set to “1”). However, erasing can only be done in chunks called “blocks”, with a block typically containing many pages. This significantly complicates the management of the flash memory devices, as data cannot simply be written into a random address without first making sure it is erased, but one cannot arbitrarily erase a target page as its neighboring pages sharing the same block might contain valuable data that should not be erased. Another example of the complexities of using flash memory is the need for error correction. Flash memory cells tend to have occasional errors when being read out and the storage system must provide appropriate mechanisms for correcting the data read out before returning the data to the requesting application.
In order to handle the above difficulties (and some others) it is common to access flash memory systems through a software layer that takes care of all complexities and provides the accessing application a simple-to-use world view. Such software layers are commonly called “flash management systems” or “flash file systems”. Typically such software executes within a flash controller dedicated for controlling and managing the flash memory devices or within a host computer accessing the flash memory devices where the software is part of a software driver servicing the storage system.
Flash management systems typically require the storing of metadata (also called “control information”) within the flash memory. Such data is essential for deciding on the right policies and activities to be employed by the flash management systems. A most simple example is the storing of the erase count of each of the blocks in the storage system. As there is a desire to level out the usage of blocks across the storage system (as blocks wear out with extended use), it is typical for a flash management system to maintain for each block its number of accumulated erasure cycles and use this data for deciding on the next block to be allocated for writing new incoming data. There are many more examples of metadata stored in flash storage systems, some of them common to most systems and others unique to specific storage systems that employ unique management algorithms. While the present disclosure discusses specific examples of metadata, it should be understood that the methods described herein are equally applicable to all types of metadata that are associated or used with flash memory storage systems, as long as such metadata types comply with the conditions specified elsewhere in this disclosure as benefiting from the methods disclosed herein.
Many of the metadata types commonly used are block-specific. By block-specific it is herein meant that the metadata provide some information that is a characteristic of the block as a whole. The above example of an erase count of a block is block-specific. As a block is the minimal unit of erasure, there is no point in providing an erase count for a single page. There are however metadata types that are page-specific, in the sense that they provide information related only to a specific page, and different pages within the same block may have different metadata values. One common example for page-specific metadata is the error correction parity bits typically stored with each page of user data to enable error correction when reading the page. Obviously the values of these parity bits depend on the specific data stored in a page and therefore must be page-specific. Block-specific metadata are much “cheaper” to handle in flash memory systems than page-specific metadata. This is because block-specific data require just a single entry per each block, while page-specific data require an entry per each page. As the number of pages is typically significantly higher than the number of blocks, the handling of page-specific metadata creates great difficulties for flash management systems. The difficulties exist both in the need for more metadata space within the flash memory devices and in the need for larger amounts of RAM memory in the flash controller or host computer (as the case may be) for storing tables of the metadata values for various pages.
Another example of page-specific metadata is needed by some known methods for improving reading reliability in flash memory systems by adaptively adjusting the reading reference voltages used for reading the flash memory cells. In one such known method the flash management system keeps track of the adjusted read reference voltages successfully used for reading each page the last time it was read. Those reference voltages are then used as a starting point the next time a page is read, thus reducing the number of reading iterations on next reading operations.
The stored last-used reference voltages provide another example of page specific metadata. Even though all pages in a common block are erased at the same time and typically have similar threshold voltage drifting characteristics, their reference voltage metadata values are not necessarily the same. This is because writing time is not necessarily common even though erasing time must be common for all pages in a block. Typically a flash management system directs an incoming stream of consecutive page write requests into sequential pages in a block. If the stream of pages being written at a first date stops at a point that corresponds to a middle of a block and then starts from there at a later date, then the same block would contain some pages written on the first date and some pages written on the second date. In more complex scenarios, and depending on the specific algorithms of the flash management system, a block might contain pages written on more than two dates. In extreme (even though quite unlikely) scenarios, it is even possible to have each page of a block written on a different date. If the host writes pages at random addresses rather then sequentially, the result is even more likely to be many blocks with pages written at different dates.
The amount of drifting of the threshold voltages of cells is strongly dependent on the time of writing. A page written a year ago will typically have a significantly higher drift than a page written an hour ago. Drifting only starts after a page is written. Because of this, reference voltage metadata are considered page-specific metadata in conventional flash management systems. As such, the handling of reference voltage metadata is subject to difficulties similar to those mentioned above—extra space needed in the flash memory devices and extra RAM needed in the flash controller or the host computer. Accordingly, there is a need for improved handling of page-specific metadata.